Are you feeling the impact of AI in your daily work? No? Your database might say otherwise. If you run a forum, threads, posts and messages that are forwarded to the database are likely to be at least partially AI-generated. Run a search engine deriving information from a database or two? You’re likely to have suggestions from users or customers related to AI. AI is here and, while it’s unlikely to destroy us and take over the world (at least for now), it’s here to stay. That’s a fact.
Nowadays, more and more enterprises integrate AI into their applications, servers, and databases. Given the fact that databases aren’t just repositories of information but backbones for your applications, securing databases like MySQL and PostgreSQL is becoming increasingly critical and, while we can use basic security practices to secure our most precious data, some things have to change.
Understanding security from the perspective of AI
First off, the basics of data security remain the same: access control is still vital, data encryption comes without question (did you know that Google Chrome will now throw an error if you’re visiting a website not using SSL?), regular auditing and monitoring is still a necessity if you want to comply with privacy regulations, and backups (you verify them, right?) are – and will – continue to be important in the age of AI.
Considering that the evolving nature of AI introduces new challenges that can bypass conventional security mechanisms, it’s important to be aware that:
- AI-driven attackers will perform actions faster: while traditional security models such as web application firewalls and signature-based malware detection are still effective if they’re tested before being deployed on a live application, you need to keep in mind that nefarious parties will consult AI about your infrastructure if they’re not sure. AI can (and will) make mistakes, but it will inevitably make sophisticated attacks a little faster.
- AI models work by aggregating public data and training on it: AI chatbots like ChatGPT act like humans in conversations. To make that possible, they have to be trained on large datasets of text, and work by:
- Acquiring and analyzing public data.
- Fine-tuning their models and thought processes based on public data.
- Providing snippets of processed public data based on a query.
Once we understand these elements, it becomes a little easier to frame AI not as a monster, but as another tool that may be used or abused.
- AI will assist in reconnaissance: keeping in mind that AI is a tool that helps perform actions faster for attackers, we come to reconnaissance. Hackers will frame questions in such a way that causes chatbots like ChatGPT to return actionable advice on how to scan for exposed credentials, where to find poorly-secured APIs, or what permissions may be misconfigured judging from public data.
- Actions, like scraping, are made easier: with AI’s ability to aggregate and synthesize vast amounts of data, attackers will leverage tools like AI-enhanced scraping or fuzzing to pinpoint database vulnerabilities with greater accuracy.
The bottom line is this: while traditional defenses like firewalls and signature-based malware detection remain critical, the speed and sophistication with which AI-driven attackers can adapt and execute their strategies makes it increasingly difficult to rely solely on older security advice. Attackers leveraging AI move faster through reconnaissance, data aggregation, and pinpointing vulnerabilities, thereby shortening the window of time for successful exploitation.
This means that securing databases like MySQL and PostgreSQL requires more than just vigilance: it necessitates proactive actions and tools that can anticipate and counter AI-enhanced attacks.
Protect your data. Demonstrate compliance.
How to secure MySQL in the world of AI
If we look at security best practices as users of MySQL, one thing that becomes clear immediately is that safeguarding sensitive data goes beyond securing the database itself. Below are some best practices:
- Implement strong authentication mechanisms for all of the users in your database: the foundation of database security begins with authentication. If attackers can gain access to the database as a result of your administrators using weak or compromised credentials, the rest of your security measures become irrelevant.
- Don’t store passwords if they’re unnecessary – use strong hashing algorithms like BCrypt or Blowfish if you must store them: avoiding storing passwords may make GDPR irrelevant for your use case. Hashing passwords using Blowfish instead of MD5 may make them unfeasible to start cracking after a hack.
- Implement brute-force detection and blocking mechanisms within your application (not allowing the same user to log in more than X times in Y minutes is a good start.) This makes your application resilient to brute force and credential stuffing attacks.
- Enforce strong passwords and the usage of 2FA (two-factor authentication): disallow the registration of users that have passwords of less than X characters and ask them if they want to enable 2FA upon registration (if you’re using a CMS, there are plugins for this.)
- Enforce external authentication mechanisms if possible: why not ditch logins and use SSO (single sign-on) if the situation allows for it?
- Encrypt sensitive data: ensure that all data transmitted between clients and your database is encrypted by using SSL for database connections. This prevents data interception during transit, protecting it from man-in-the-middle attacks. Also, don’t forget that MySQL supports encryption functions that allow for a granular approach to security.
- Keep MySQL up-to-date: keeping MySQL (and the rest of your software) up-to-date is a crucial part of any security strategy. Updates matter because MySQL often releases patches that fix security vulnerabilities as well as introduce performance updates. The same goes for the operating system powering your servers and the software within your application. Keep everything updated and you’ll have one less thing to worry about.
- Monitor and audit the activity within your database: when was the last time you’ve cleared your MySQL log files after performing a review? MySQL has logging capabilities that track user activity and error messages. Enable the general log to track all SQL statements within your database and the error log to capture system errors and security warnings. You may also want to back up crucial log files to another server: that will be helpful in the event of a compromise if the logs are wiped.
- Cater towards privileges for your users: the principle of least privilege may become your last straw if a user is compromised. There’s little use in compromising a user that only has ‘read’ privileges.
- Plan for backups: if possible, automate at least some of your backup procedures and test your backups for restoration capabilities upon generating them. MyISAM, which is prone to corruption, isn’t used much nowadays – but your server is still prone to natural disasters and disk failure.
- Decide on a way to store your backups: store logical .sql files or raw data dumped using
SELECT...INTO OUTFILEand, depending on your circumstances, consider physical backups and store them in at least two different locations (including one off-site.)
- Limit backup file access to only those who absolutely need it – or don’t store them on your server at all.
- If possible, encrypt your backups, or the disk they’re stored on.
What else is important?
These are all things you need to take care of when running MySQL – but, using MySQL is only necessary if you have an application facilitating a wider use case. That’s why you need to take care of the security of your application too. So, when using MySQL in conjunction with an application facilitating a use case, it’s wise to do the following:
- Remove any identifying markings related to your software of choice: if you’re using a CMS or similar software, it’s very likely that it’ll leave its marks in the footer or elsewhere. With AI, attackers can ask what security vulnerabilities are prominent in the specific version of software you’re using, and then use the information against you and your application. Simply remove “Powered by:” (or similar wording) from the footer.
- Secure the back-end of your application by following best practices like input validation and sanitization, prepared statements or PDO, a firewall to filter out malicious traffic and requests, and implement safe authentication mechanisms as described earlier.
- Consider limiting access to parts of your website, including phpMyAdmin for MySQL: set up an .htaccess file that grants or denies access to panels like phpMyAdmin based on a set of rules, limiting access to MySQL by IP address to ensure only trusted sources can connect to the database server.
- Avoid using root for everyday database tasks: because root is a power user, its compromise could result in major consequences. Instead, opt to create specific users with the least privileges needed for the task.
- Set up cronjobs to remove unused data and files: files or data dormant for 12 months or more? Time to look into them once more and remove them if necessary.
- Take a close look at all of your files: do any of them reveal any compromising information in the comments? This includes configuration files, server-based files, files included into other files, etc.
Enjoying this article? Subscribe to the Simple Talk newsletter
How to secure PostgreSQL in the world of AI
To secure PostgreSQL instances, you can take anything applicable to your use case from earlier in the article, but keep in mind that Postgres has some quirks and features unique to itself. You can use some of these to your advantage, including (but not limited to):
- pgAudit: pgAudit (PostgreSQL Audit) is an extension for PostgreSQL that aims to provide a robust and customizable auditing solution for tracking database activity within PostgreSQL. This PostgreSQL extension enables administrators to log detailed information about almost all operations within their database, including CRUD operations and other actions. The usage of pgAudit is exclusive to PostgreSQL and can help greatly enhance both security and compliance by ensuring a comprehensive record of who did what, when, and how.
- pgCrypto: by incorporating pgCrypto into their database, users of PostgreSQL can encrypt and decrypt sensitive data, securely manage cryptographic keys, hash data and create digital signatures, thus ensuring compliance with data protection regulations.
- pgBouncer: pgBouncer is a connection pooling middleware for PostgreSQL that sits between client applications and your PostgreSQL database server. Since its primary function is to manage connections to Postgres and ensure effective handling of resources, PostgreSQL will be able to handle more concurrent client connections without overloading itself. Not directly security-related, but if Postgres gets overloaded and your users start leaving, security becomes secondary.
- pg_hba.conf: the pg_hba.conf file is at the core of PostgreSQL’s access control system and plays a crucial role in managing who can connect to the database, from where, and how. This is the file used by PostgreSQL to control who can connect to the database using what authentication methods. Each line in the file defines an access rule.
- Row-level security: all tables within PostgreSQL can have row-level security policies that instruct the database which rows can be interacted with using SQL queries. Row security policies can be applied to commands, roles (collections of privileges), or both of them.
As for other best practices, it’s the same story as ever: use strong authentication (and don’t forget about 2FA), monitor what’s going on within your application and database, use the principle of least privilege, and encrypt and back-up your most precious assets.
Summary and Next Steps
In this day and age, securing MySQL, PostgreSQL and other database instances is no longer as simple as taking care of a set of privileges – but it’s not rocket science either. The happy medium lies somewhere in between understanding how your database of choice functions, what you can do to make it function safer, and building upon those principles.
While AI does accelerate the processes necessary for nefarious parties to work against you, it can’t do so without increasing your chances to defend against them. Follow basic security practices, evaluate your specific use case, apply the relevant best practices outlined in this article, and you’ll be good to go.
FAQs: How to secure MySQL and PostgreSQL in the world of AI
1. How is AI impacting database security?
AI accelerates both defense and attack strategies. While organizations use AI to improve monitoring and automation, attackers can also use AI for faster reconnaissance, vulnerability scanning, and credential discovery – making proactive database security essential.
2. Why is securing databases like MySQL and PostgreSQL more critical in the AI era?
Databases such as MySQL and PostgreSQL are the backbone of modern applications. As AI-powered tools make attacks faster and more precise, traditional defenses alone are no longer enough to protect sensitive data.
3. Can AI-driven attackers bypass traditional security tools?
AI can enhance reconnaissance, automate scraping, and speed up vulnerability detection. While firewalls and signature-based detection still work, they must be combined with strong authentication, encryption, monitoring, and least-privilege access controls.
4. What are the top security best practices for MySQL?
Key MySQL security measures include:
-
Strong authentication and 2FA
-
Least-privilege user roles
-
SSL/TLS encryption for connections
-
Secure password hashing (e.g., bcrypt)
-
Regular updates and patching
-
Activity logging and auditing
-
Encrypted, tested backups stored off-site
5. How can I secure PostgreSQL against AI-enhanced threats?
PostgreSQL offers built-in and extension-based security features such as:
-
pgAudit for detailed activity logging
-
pgCrypto for encryption and hashing
-
pg_hba.conf for strict access control
-
Row-level security policies
-
Strong authentication and encrypted backups
6. Does AI change basic database security principles?
No. Core practices like access control, encryption, auditing, monitoring, and backups remain fundamental. AI increases the speed and scale of threats but solid security foundations still provide strong protection.
7. Should I modify my application security because of AI?
Yes. Remove publicly visible software version details, secure admin panels (like phpMyAdmin), use prepared statements, validate inputs, and restrict database access by IP. Application-level security is just as important as database-level protection.
8. What's the biggest takeaway for database security in the age of AI?
AI makes attacks faster, but it also enables better defense. By combining traditional security best practices with proactive monitoring and hardened configurations, you can effectively secure MySQL and PostgreSQL in an AI-driven world.
Load comments